昨天那篇收在「文件組裝完之後，鼠勾以怎麼把整份 PRD 再交叉檢查一遍」。今天就講這道關。
「你流程圖這個 UI-07 是什麼？下面清單只到 UI-06 欸。」
這是 SA 看我那份 PRD 的第一句話。還沒有這道關的時候，我手動組了一份文件拿去討論，流程圖畫得漂漂亮亮，畫面清單也列得整整齊齊，我自己看了三遍覺得沒問題。結果開場第一句就被點出一個對不上的編號。
我那時候才發現，一份需求問了四十分鐘、橫跨七八個區塊，每一塊我都顧得很好，可是組起來的那一刻，塊跟塊之間的縫隙沒人在看。流程圖是區塊 5 畫的，畫面清單是後面才整理的，中間我加了一個 Loading 畫面忘了補回去。每個動作都對，湊起來就漏了。
人檢查自己剛寫完的文件，本來就很容易有疏漏。你腦子裡記得「應該長這樣」，眼睛就會自動把它讀成那樣，漏掉的地方你看不見。這時候有一個不帶預設、會老老實實一條一條對的 AI 在旁邊幫你過一遍，補上的正是人眼最容易跳過的那些縫，整份內容就完整得多。
從那之後，鼠勾以就多了一道「出貨前自己驗一遍」的關卡。
Day 24 講的挑戰跟矛盾偵測，處理的是對話進行中的問題。使用者答一題，它當場拿這題去對前面幾題，發現不一致就立刻提出。那是即時的、逐區塊的檢查。
今天這道自檢不一樣，它跑在最後：所有區塊都問完、PRD 草稿都組好了、待確認項目也標了，就在「顯示文件預覽給你看」的前一秒。等於是把整份文件攤在桌上，從頭到尾再對一次帳。
為什麼即時挑了還要再來這一遍？因為有些不一致是組裝出來的。對話途中每一塊都站得住，可是把流程圖、畫面清單、欄位規格、例外情境、分數這些東西拼成一份文件時，新的縫隙才會冒出來。即時挑戰看不到這層，因為那時候文件還沒拼起來。
所以它的定位是「出貨閘門」，不是全程監控。它管的是「這份要交出去的東西，內部對不對得起來」。
鼠勾以這道關會跑七類機械檢查，我快速帶過前六類，第七類單獨講。七類之外還有一類專門查「結構」的，跟前面不太一樣，也單獨拉出來說。這些跑完其實還沒結束，最後它會換一種完全不一樣的眼睛再讀整份一遍，那個放到最後說。
A 類：流程圖對畫面清單。 就是我開頭那個坑。流程圖裡每個畫面節點，畫面清單裡有沒有？反過來清單裡的畫面，流程圖有沒有用到？數量對不對？順便還做兩件事：揪出混進流程圖的純後端動作（「呼叫」「驗證」「儲存」這種不該是畫面的節點），以及補上那行讓 Mermaid 畫直角線的設定，少了它圖會歪。
B 類：欄位對驗收標準。 區塊 6 收的每個要使用者手填的欄位，AC 裡有沒有對應的驗證條件？標了「必填」「不可重複」的欄位，有沒有寫到「沒填怎麼擋」「填重複怎麼辦」？漏了就補一條，標待確認。這一類最近還多看一件事：AC 的用詞。如果某條驗收標準寫成「呼叫扣點 API」「畫面要順暢」，前者把實作做法寫死、後者根本沒辦法判斷算不算過，它會把這幾條挑出來，建議改成「點數餘額正確減少」「3 秒內完成」這種看得到、測得出的講法。一樣只標不改，怎麼收你說了算。這條鐵律明天講模板的時候會再講細一點。
C 類：例外情境對流程圖。 區塊 7 講好的錯誤情境，流程圖裡有沒有對應的錯誤分支？錯誤之後要導去的畫面，真的存在嗎？
D 類：待確認項目有沒有漏。 對話裡你說過「這個我不確定」的，最後那份待確認清單有沒有收進去？正文標了待確認的，清單裡找得到嗎？這類最容易漏，因為待確認的東西本來就散在四十分鐘的各個角落。
E 類：跨區塊一致性。 這類直接複用 Day 24 那五種矛盾的偵測規則（目標對功能、指標對功能、時程對範圍那些），差別只在這次是組裝後再全面複檢一遍。
F 類：系統決策有沒有填齊。 PRD 最前面那張系統架構決策表，五個欄位是不是都有答案？文件內文提到「審核」「通知」「報表」這些字，有沒有對應的系統決策被帶出來？沒有就補，並提醒這格要留給 SA 確認。
G 類是計分一致性，起因很實際。
鼠勾以的 SA 就緒度分數是每答一輪就即時加上去的。你補完一塊，分數往上跳一點，畫面顯示新的總分。問題是，這一整段對話從頭到尾，沒有任何一個環節對過總帳。即時加分加了二三十次，中間漏加一塊、或某塊重複加，分數就會偏掉。系統不會報錯，只會顯示一個錯的數字，而使用者通常不會去質疑它。
這類檢查的做法有個關鍵：要從頭重算一次，不能拿先前顯示的數字來對。如果只是把畫面上那個總分讀回來再比，等於把錯誤一起讀進來，怎麼比都一致。所以它會照配分規則，把所有「已確認」的面向重新加總一遍，再跟顯示的數字對。對不上，以重算的為準，還會告訴你是哪一塊漏加或重複加。順便檢查有沒有哪一塊算超過上限、或把「還沒確認」的面向偷偷算進分數。
做法就是要求它重新算一次，而不是引用自己先前算過的結果。模型引用自己上一步的輸出，錯誤會一路被延續下去。
前面七類都在比「兩個東西兜不兜得攏」。可是我後來踩到一個坑，這七類全部接不住。
有個需求方PM 拿了一個功能來，是讓使用者自己補回前幾天的運動數據。他配合度很高，跟著鼠勾以一題一題答完，所有區塊跑滿、就緒度滿分，然後叫它出 PRD。產出的東西跟模板完全對不上：章節是模型自己編的，從一排到二十幾；每個功能該展開的詳細規格整段不見；畫面清單該有九欄，只剩三欄；連文件名都被改掉，不叫「需求討論書」，叫「規則書」。
奇怪的是七類全綠。原因是那七類查的是「對不對得起來」，而這份文件內部並沒有任何互相牴觸的地方，它是整塊章節都沒產出。七類抓的是兩塊對不上，整塊缺席這種情況它偵測不到。
所以我又補了一類，這類不看內容對不對，只數該有的有沒有在。需求完整度總覽呢？每個功能是真展開了，還是一行帶過？章節編號是照模板走，還是它又自己排了一份一到二十幾的目錄？
但這一類有個問題我一開始沒發現：它可能整個空轉，而且從報告上看不出來。問題在它「拿什麼當答案在對」。它要對照「應該長怎樣」，可是這份「應該」如果是模型自己剛掰出來的那個走樣版本，那它對起來當然一致，因為它在跟自己比，怎麼比都過。對話一長，模型早把模板忘了，改照「補登規則、寫入規則」這種主題自己編章，順手就把這道該攔它的檢查也一起帶歪了。檢查照跑、報告照說通過，可是它手上那把尺是歪的。等於空轉。
後來我補在兩個地方。一個是那份每次都會先讀的指令，最前面把話說死：產出的時候，章節骨架要一節一節對上模板，不准自己編號、不准改文件名，就算這個需求講的全是規則，也得把規則塞進對應功能的需求跟驗收裡，不准另外開一堆扁平章節去頂掉功能規格。另一個是在出文件的流程裡：要產出之前，先把模板骨架原樣重建一次，再一格一格填進去，以模板為準，別拿前面已經寫過的段落當範本，也別跟著使用者匯入的舊檔結構走。這樣那道檢查手上才有一份真模板可以對，不是自己跟自己比。
這跟前面 G 類是同一個結構的問題。G 那邊模型會引用自己算過的分數，這邊模型會照自己剛編出來的結構幫自己蓋章。解法也一樣：要求它退回最原始的依據重做，不採用自己上一步的輸出。自檢真正的風險不在漏看，而在於它照著一份已經錯掉的基準在檢查。
前面那七類有個共同點：都在問「文件內部對不對得起來」。編號接不接得上、欄位漏沒漏 AC、分數有沒有算錯。它們很會抓「兜不攏」，可是有一種洞它們天生抓不到，那種要有「拿到這份 PRD 的人」的專業腦袋，才讀得出來的洞。
舉一個實際遇到的例子。有份 PRD 自檢全綠，編號都對、欄位都齊，我就直接拿去開會。SA 看了三分鐘問：「兩個人同時改同一筆，誰贏？」我答不出來。並發這件事，七類機械檢查一個都不會問，因為文件內部沒有任何地方不一致，它就只是少了一塊。結果就是又補一輪。
所以最後補了這一道，做法就是讓鼠勾以分別戴上三頂帽子，把組好的整份 PRD 各通讀一遍：
工程師：拿到這份能不能直接開工？有狀態、有清單、有金流的功能，並發跟重複提交講了嗎？串接外部，講清楚是哪個系統了，還是只寫「串接外部」？流程用到的資料，每一筆都有明確來源嗎？
QA：每條 AC 我測得了嗎？有沒有哪條要靠猜才知道算不算過？關鍵流程有對應的驗收嗎？取消、釋出這種行為，有沒有講「什麼時候生效」這種測得到的時間點？
SA：這份夠不夠開設計會議？範疇清楚到能估架構嗎？有沒有「說了要做、但放在哪個系統還沒定」的功能？要確認的事，有沒有指定誰負責？
關鍵是它只補機械檢查抓不到的新洞。前面七類已經抓過、已經列進清單的，這一道絕不重複報，免得同一個問題在報告裡出現兩次。它要找的是並發、依賴對象、可測時間點、功能跟目標到底連不連得起來這種，得靠角色專業判斷、機械規則畫不出來的東西。
一樣不擋你出貨，也不會因此扣分。抓到的洞分輕重列進待確認清單，等於把「SA 待會會問什麼」先搬到你眼前。這道關的目的就一句：讓那場會議少一輪「啊這個我們沒想到」。
前面那些檢查，不管是七類對帳還是三頂帽子，盯的都是「已經寫進文件的東西」。但有一種洞，文件上根本不會有，因為使用者從頭到尾就沒提過。
我做這個工具的時候查過一篇研究（前面提過的 LLMREI），它拿 Bano 那套訪談錯誤分類去評估 AI 做需求訪談，挑出來的結構性弱點之一就是：AI 偵測不到「使用者沒說出口的需求」。挑戰機制能處理「說了但講得模糊」，題庫能涵蓋「常見但忘了問」，可是有些東西使用者心裡有、卻因為覺得理所當然或一時沒想到而沒講，這幾道關全都接不住。
所以我在出貨前加了一個很直接的步驟：問使用者一句。
在我整理成文件之前，最後問你一句：有沒有什麼你覺得重要、但我剛剛都沒問到的？
就這麼一句開放問題。前面四十分鐘都是鼠勾以帶著問、使用者跟著答，這一步把發言權交回去。實測下來使用者常常會補一句「這個功能只有主管能開」之類前面沒有被任何一題問出來的資訊。這一句的成本幾乎是零，接到的通常是上線後才會出問題的隱性需求。
這一步補的是三頂帽子也補不到的地方。三頂帽子是鼠勾以站在工程、QA、SA 的角度推他們會追什麼，那終究是它自己的推斷；使用者腦袋裡那塊資訊，它再聰明也猜不到，只能開口問。這種只有當事人知道的事，不問，就只能等上線後自己冒出來。
不是每個問題都要丟回來煩你。鼠勾以分三種情況：
能自己補的就靜默補。流程圖漏的畫面、欄位漏的 AC、分數加錯，這些有明確修法的，它直接補進草稿、標個待確認，不打斷你。
補完但想讓你知道的，會在預覽前講一句：「我補了幾個小東西，你待會在預覽裡確認一下對不對。」
真的需要你拍板的（像流程圖結構性的缺、或邏輯上的矛盾），才列一份簡短的自檢報告，一個問題一句話講「什麼東西對不上」，配一句建議，最多列五個，多了就摘要。然後給你兩條路：逐一處理完再看預覽，或先看預覽、這些先幫你標在文件裡。
整個設計的精神就一句：它是出貨前的最後一道閘門，不是幫你做決定的人。對不上的它指出來，要怎麼收，還是你說了算。
把這幾道關攤開來看，前七類在替我對帳，最後那道在替我換位思考，它們其實都在做同一件當年我自己沒做好的事：交件之前，把整份文件當成別人的東西，挑剔地再讀一遍。人很難對自己剛寫完的東西這樣狠，但工具可以。
明天進產出的核心：那份 PRD 模板本身長什麼樣，為什麼所有東西要塞進同一份文件、而不是拆成一疊。
這是 iThome 鐵人賽系列文章。明天見。
iThome鐵人賽
看影片追技術